In jEdit 4.3pre8 LazyImporter's 'remove unused imports' removes imports of classes
that are implemented by the present class and not otherwise referenced in the source
file.
example:
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
final class MyActionListener implements ActionListener{
public void actionPerformed(ActionEvent e){
}
}
becomes
import java.awt.event.ActionEvent;
final class MyActionListener implements ActionListener{
public void actionPerformed(ActionEvent e){
}
}
which will not compile.
LazyImporter 1.08 and jEdit 4.3pre8
| Submitted | ringler - 2007-01-11 - 14:07:28z | Assigned | nobody |
|---|---|---|---|
| Priority | 5 | Category | None |
| Status | Open | Group | None |
| Resolution | None | Visibility | No |
| 2007-01-17 - 10:48:20z ringler |
Logged In: YES user_id=730046 Originator: YES After I have had a look at the source of org.etheridge.lazyimporter.importer.JavaClass I think the problem will probably go away if '{' is included with the String constant msValidPostClassCharacters. So line 88 should be private static String msValidPostClassCharacters = "\t)( .\n[,;{"; instead of private static String msValidPostClassCharacters = "\t)( .\n[,;"; Until this is fixed you can circumvent the problem by inserting a blank between the name of the implemented class and the curly bracket. The problem does not arise in the modified example import java.awt.event.ActionEvent; import java.awt.event.ActionListener; final class MyActionListener implements ActionListener { public void actionPerformed(ActionEvent e){ } } |
|---|---|
| 2007-01-17 - 12:09:45z ringler |
Logged In: YES user_id=730046 Originator: YES By the way, neither msValidPreClassCharacters nor msValidPostClassCharacters needs to contain '\n' since '\n' is removed by the StringTokenizer. Maybe, it would be better anyway to replace isValidPostClassCharacter(char ch) with !Character.isJavaIdentifierPart(char ch) and isValidPreClassCharacter(char ch) with (char c != '.' && !Character.isJavaIdentifierPart(char ch)) It is rather obvious that this way findClassUsage will not miss any class uses. And i suppose there will not be too many additional false positives. Anyways, false positives are less severe than false negatives in this case, since an unnecessary import that survives is much less of a problem than a necessary import that is removed. |
| 2007-01-17 - 12:39:37z ringler |
Logged In: YES user_id=730046 Originator: YES File Added: JavaClass.patch |
| 2007-01-17 - 12:39:36z ringler |
JavaClass.patch |
|---|